NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/14178

Text File | 1996-08-05 | 5.7 KB | 152 lines

Path: hoho.quake.net!usenet
From: [e-mail] (Bill Foote)
Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
Date: 29 Mar 1996 07:55:27 GMT
Organization: Jovial
Message-ID: <4jg51f$[e-mail]>
References: <4j954n$[e-mail]> <[e-mail]> <4jefbd$[e-mail]>
NNTP-Posting-Host: l89.ip.quake.net

In article <4jefbd$[e-mail]>, Arch Robison <[e-mail]> wrote:
>In article <[e-mail]> [e-mail] writes:
>>If resumption semantics were inferior, why should we bother to get
>>its "benefits" by simulating its semantics as below:
>
>I should have qualified my statement "inferior" to "inferior in most cases".

I'm still puzzled how providing *additional* functionality can make
resumable exception semantics "inferior" (except for implementation
considerations), but that's a nit.

>     bool retry;
>     do {
>     retry = false;
>     try {
>         result = do_something();
>     }
>     catch( condition1 ) {some_extraordinary_work1();  retry=true;}
>     catch( condition2 ) {some_extraordinary_work2();  retry=true;}
>     catch( condition3 ) {some_extraordinary_work3();  retry=true;}
>         catch( condition4 ) {result=NULL;}
>     } while( retry );

Well, here I go again, disagreeing with Bjarne, but:

This example misses the point of resumable exceptions.  If you can sensibly
catch the exception at the point from which you want to resume, yes, of course,
you don't need resumable execeptions.  Resumable exceptions only buy you
something if the point where you can deal with the exception is one or more
stack frames _above_ the point where the error occurs.  Here is an example
of something that you can't simulate with termination semantics:

    main()

    {
    try {
        call_something();
    }
    catch ( OutOfMemoryException& ex)  {
        do_something_to_free_up_some_memory();
        if (a_decent_amount_of_memory_was_freed())
        retry;
    }
    }

    void call_something()

    {
    <...>
    call_something_else();
    }

    void call_something_else()

    {
    <...>
    try {
        auto_ptr<char> = malloc(A_REALLY_BIG_NUMBER);
    }
    }

The idea here is that the only place with enough context to know how
to free up some memory (perhaps by flushing some caches or something)
is main().  call_something_else() exists at too low a level to know
how to do that.  If memory is low, the malloc() fails, and the exception
handler in main() catches it, and then resume causes execution to go back
to the point of failure.


Now, Bjarne's claim is that, in practice, doing this sort of thing isn't
useful.  He backs this up with reports of real-world experience, where
large systems were built, and resumption semantics were found to not be
useful, in practice.

This contention I cannot disagree with -- I don't have any experience
with large systems using resumption semantics for its exceptions.
It's pretty easy to concoct toy example where it seems compelling,
but that doesn't really demonstrate that, in practical terms, it's
useful.  (Of course, three or four case studies doesn't guarantee that
it *isn't* useful, but it certainly supports the contention).

Does anyone out there know of examples from large systems where
resumption semantics proved valuable?

>The original attack on C++ unfairly implied that the C++ committee had given no
>though to the issues.

As the author of the "attack", I respectfully disagree.

I did not mean to imply that the C++ committee gave no thought to the issue.

I *did* imply that the fact that implementing resumable exceptions would
be hard may have influenced the decision of the committe to not support
them.

(Incidentally, I did not think of my comment as an "attack".  Perhaps
a "jibe", or "poking fun", but attack is much too strong a word.)

>As described in Stroustrup's D&E book, the C++ committee
>knowledgeably debated the resumption vs. termination models of exception
>handling and judged that the extra cost of the resumption model was not worth
>the cost in added complexity.

Exactly.  Given the definition of C++, it would be hard to implement
resumable exceptions.  This may have played into the decision not to do
it.  I think we're in violent agreement :-)

>Thus many apparently useful features are deliberately left out of C++ .
>Users who want the features can simulate them without burdening others.

Aak!  Some things are very, very difficult to "simulate" without runtime
support from the language.  Off the top of my head:

    *  Simulating MI in a SI language would be tough

    *  Block closures, and curried functions.

    *  Garbage Collection (with, of course, finalization and weak
       references) is hard to "simulate".  (Not impossible, but
       much, much harder than if it's put in the language).

    *  Resumable exceptions

    *  Meta-information.  (For example, try to write a framework that
       automatically "pickles" an arbitrary C++ object.  You end up either
       forcing the client to write his own pickling/unpickling code, or
       relying on a preprocessor.  Both are painful.)

    *  RTTI a la C++.  dynamic_cast<T> is *awfully* hard to "simulate"
       for all but trivial uses in a pre-RTTI C++ compiler.

>C++ is not intended to be the best language for all problems.
>If another language is better for your problem, use it.

Of course.  But does that mean that all critical thought as to the merits
of C++ should stop?  I certainly hope not!

--
Bill Foote                       |  L'homme est nΘ pour vivre dans les
[e-mail]                 |  convulsions de l'inquiΘtude ou dans la
http://www.jovial.com/~billf/    |  lΘthargie de l'ennui       -- Voltaire